Electronic Card

ABSTRACT

An electronic card has a power source, a user selection mechanism operable to allow a user to select a customization variable for a single transaction, a processor for generating a transaction specific data packet that includes a card number and a customized number and an electronic communication device operable to cause the data packet to be read by a read head of a magnetic strip reader. The electronic communication device is operable to dynamically convey the transaction specific data packet to a read head of a magnetic card reader so that the transaction specific data packet is read by the read head. The transaction specific data packet is dynamically generated for use by the card for the single transaction of the card and the customized number is determined based upon the customization variable selected by the user selection mechanism.

CROSS REFERENCE TO RELATED APPLICATIONS

The present application is a continuation application of U.S. patentapplication Ser. No. 13/438,710 filed Apr. 3, 2012 which was acontinuation of U.S. patent application Ser. Nos. 10/968,399 and10/968,401, both of which were filed Oct. 18, 2004, both of which werecontinuation applications of U.S. patent application Ser. No.09/960,714, filed Sep. 21, 2001, which was a continuation-in-partapplication of U.S. application Ser. Nos. 09/667,081 and 09/667,089,filed Sep. 21, 2000, which are continuation-in-part applications of U.S.Ser. No. 09/659,434, filed Sep. 8, 2000, which is a continuation-in-partof U.S. Ser. No. 09/640,044, filed Aug. 15, 2000, which is acontinuation-in-part of U.S. Ser. No. 09/619,859, filed Jul. 20, 2000,which is a continuation-in-part of U.S. Pat. No. 6,592,044, all of whichdisclosures are specifically incorporated herein by reference. Thepresent application is also related to U.S. patent application Ser. Nos.09/667,835, 09/667,089, and 09/667,082, all of which were filed on Sep.21, 2000, and all of which are specifically incorporated herein byreference.

FIELD OF THE INVENTION

The present invention is in the field of cards readable by a magneticstripe reader.

BACKGROUND OF THE INVENTION

Three forms of money in widespread use today throughout the world arecash, checks and payment cards (debit or credit). Each has distinctadvantages, and distinct disadvantages. Cash is readily accepted, easyto use and anonymous, but it does not earn interest, it can be lost orstolen, and it is not always readily accessible. Checks are not alwaysaccepted, but they offer many advantages, since they do not have to bewritten until the time of payment. However, they must be physicallypresented and they are not anonymous. Payment cards are readily, but notalways, accepted, and they offer many advantages over checks. If thecard is a credit card, payment can be deferred, but the transaction isnot anonymous. If the card is a debit card, payment has usually beenmade prior to its use, but it is anonymous. Accordingly, it is apparentthat different types of money have different advantages to differentpersons in different situations. This may be one reason why all theseforms of money are still in widespread use, and are even used by thesame persons at different times.

As society and international commerce have become more dependent uponelectronic transactions, money has also become more electronic. Manyattempts have been made to come up with suitable forms of electronicmoney that mimic the physical world, or even create new forms ofelectronic money. However, despite the enormous need for such money, andefforts by some of the best minds and most successful companies in theworld, electronic money has suffered many setbacks and been far slowerto materialize than many had hoped or predicted. The reasons are manyand varied, but some of the obvious reasons are security, ease ofuse/operation, and unwillingness of the public and/or commerce to makeradical changes or embrace new technology and/or procedures. As aresult, many efforts, including several potentially promising efforts,have met with failure.

Even though new forms of electronic money have been slow to develop orgain widespread acceptance, electronic payments have still movedforward. Many banks now offer some form of electronic checking. Andpayment cards have been used for electronic transactions in e-commerceand m-commerce (mobile commerce). Still, there is widespread concernabout the safety of such transactions, and recent news stories haveuncovered widespread fraudulent activity associated with use oftraditional credit card numbers in e-commerce over the Internet. Inaddition, there is growing concern about consumer privacy, or lackthereof, due to widespread electronic profiling of consumers who makeelectronic payments.

Although the media has been quick to cover fraud associated with use ofcredit cards over the Internet, it is often overlooked, at least by thepublic and the media (but not the credit card companies), that themajority of fraudulent activity concerning credit cards is notassociated with e-commerce activity. Most fraud occurs in the “brick andmortar” world, and the numbers are daunting. Despite many attempts tocombat unauthorized or fraudulent use of credit cards, it is estimatedthat credit card fraud now exceeds hundreds of millions, if not severalbillion, dollars per year. And this does not even count the cost ofinconvenience to consumers, merchants and credit card issuer/providers,or the emotional distress caused to victims of such fraud, or the costto society in terms of law enforcement and preventative activities.

Accordingly, there is a very real, long-felt need to reduce the amountof fraudulent activity that is associated with credit cards, and thisneed has only grown more acute as consumers and commerce search forbetter ways to purchase and sell goods and services via e-commerce andm-commerce. However, any solution needs to be something that isacceptable to the public at large. It should be easy to use. It shouldnot be complicated or expensive to implement. Preferably, it should fitwithin the existing infrastructure, and not be something that requires agreat deal of educational effort, or a radical change in behavior orhabits of consumers. In other words, it should be user friendly, readilyunderstandable and something that does not require a completely newinfrastructure, which is a reason suggested by some as to why smartcards have not been widely accepted in the United States.

In addition, it is highly desirable that any solution to such problemsbe capable of widespread use, in many different platforms, for manydifferent applications.

In U.S. Pat. No. 5,956,699 issued in September of 1999, Wong andAnderson were the first to introduce the methodology of a system forsecure and anonymous credit card transactions on the Internet. Thispatent introduced a system which used an algorithm to use one's ownselected Personal Identification Number or PIN as one's own de factodigital signature. The algorithm instructs the cardholder how to insertone's PIN into one's valid credit card number before using it for anytransactions on the Internet. The resultant scrambled up credit cardnumber, which is tailored by the algorithm to having the same number ofdigits as before, is rendered useless on the Internet because the PINinsertion algorithm is changed automatically after every transaction.This methodology is not only capable of drastically reducing credit cardfraud on the Internet, it is also capable of safeguarding one'sanonymity, and thus privacy, in credit card purchases on the Internet.

Since the issuance of U.S. Pat. No. 5,956,699, Wong and Anderson havealso invented an anonymous electronic card for generating personalCoupons useful in commercial and security transactions, as well asvarious methods related to earlier work.

SUMMARY OF THE INVENTION

The present invention is generally directed to an electronic card havinga power source contained within the card, a user selection mechanismoperable to allow a user to select a customization variable for a singletransaction of the card, a processor for generating a transactionspecific data packet that includes a card number and a customized numberand an electronic communication device operable to cause the data packetto be read by a read head of a magnetic strip reader. The electroniccommunication device is operable to dynamically convey the transactionspecific data packet to a read head of a magnetic card reader so thatthe transaction specific data packet is read by the read head. Thetransaction specific data packet is dynamically generated for use by thecard for the single transaction of the card and the customized number isdetermined based upon the customization variable selected by the userselection mechanism.

The transaction specific data packet can include a piece of data that isgenerated by a cryptographic algorithm in response to an input from theuser selection mechanism. The card number and a cryptographic key can bestored in the card and accessible by the processor. The transactionspecific data packet can include a block of data formed by using aTriple Data Encryption Standard algorithm to encrypt a personalidentification number.

The electronic card can use a diagnostic function (such as an algorithm)to measure at least one parameter (such as checking for battery life)and generate a warning signal that is stored in the transaction specificdata packet when a preselected threshold is exceeded.

The electronic card can have a user selection mechanism, such as morethan one button (that can be located on the front of the card) thatallows a user to select between multiple transaction card functions orhandling options, such as whether the card is being used in a giventransaction for business or non-business use. A visual display can beused to indicate what transaction card function has been selected. Adisplay can visually display at least a portion of the transactionspecific data packet to the user, and such display can be triggered byinput from the user.

The electronic card, which may be contained within a telephone, canaffix its processor to a flexible printed circuit board, it can use anelectronic encoder as a communication device and it does not have tocontain n a magnetic stripe.

Accordingly, it is a primary object of the present invention to providean improved electronic card.

This and further objects and advantages will be apparent to thoseskilled in the art in connection with the detailed description of thepreferred embodiments set forth below.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a physical layout of a preferred embodiment of a UniversalAnonymous Credit Card (UACC) disclosed in U.S. Pat. No. 6,592,044 whichis one electronic card useful in accordance with the present invention.

FIG. 2 is a system block diagram of a preferred embodiment of theUniversal anonymous Credit card (UACC) useful in accordance with thepresent invention.

FIG. 3 is a physical layout of a preferred embodiment of the Universalanonymous Credit Card (UACC) useful in accordance with the presentinvention.

FIG. 4 shows an un-coded magnetic stripe likened to a series of alignedSouth-North magnetic domains.

FIG. 5 shows a sudden introduction of a strong magnet having an oppositeorientation on top of a magnetic domain of the magnetic stripe causingflux reversals.

FIG. 6 shows flux reversals caused by sudden introduction of strongmagnet having opposite magnetic orientation on top of a magnetic domainin a magnetic stripe.

FIG. 7A is an un-coded portion of a track of a magnetic stripe having 5bit cells showing no flux reversals.

FIG. 7B shows a representation of all “0”, all “1” and “0” and “1” sideby side according to the Aiken Biphase encoding code.

FIG. 7C shows a representation of decimals “0”, “5” and “9” in the AikenBiphase encoding standard.

FIG. 7D shows one embodiment of an encoder head of the presentinvention.

FIG. 8 shows one embodiment of an encoder of the present invention withdrive electronics and logic.

FIG. 9 is a simplified, schematic diagram of one embodiment used togenerate a customer one-time unique purchase order number by a customer.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The present invention is related to U.S. Pat. Nos. 5,913,203, 5,937,394and 5,956,699, the disclosures of which are all specificallyincorporated herein by reference.

U.S. Pat. No. 6,592,044 provides the following disclosure of anelectronic card.

A unitary, self-contained electronic device is provided having physicalplanar dimensions that are essentially identical to those of aconventional magnetic stripe credit card, which is widely used inelectronic commerce today. The device has seven basic components,although it is possible to combine some of these components together.

The first component is the card base. The other components, in one wayor another, are attached to this base.

The second component is a computer. It is preferable that the computerbe a single integrated chip, but it need not be. A computer typicallycontains a central processing unit connected to both storage memory andrandom access memory (RAM). RAM is used to load and run applicationprograms as well as for storing data during run time. The storage memorycan hold a variety of computer programs.

The third component is a display controlled by the computer. In thepreferred embodiment, this is a liquid crystal display (LCD). The LCDcan be controlled by a LCD driver, and the LCD driver can be containedin storage memory of the computer. In an alternative embodiment, thethird component could be an electronic ink display, which is a novel andnewly available display medium. The electronic ink display can befabricated with highly flexible physical dimensions, especially inthickness, which is likened to a thin piece of paper and also muchcheaper to manufacture than conventional LCD display.

The fourth component is an input mechanism. In the preferred embodiment,this is a keypad. However, it is possible that the input mechanism mightrely upon voice recognition as this technology becomes more and moredeveloped.

The fifth component is a magnetic storage medium. In the preferredembodiment, this is a magnetic stripe.

The sixth component is an encoder for generating a data packet that isstored in a designated portion of the magnetic storage medium. Thiscomponent is what allows the electronic device to be dynamic by relyingupon an input to generate the data packet.

The seventh component is a power source. In the preferred embodiment,this is a battery or a solar cell.

A primary function of this electronic device, which shall be referred toas the Universal Anonymous Credit Card (UACC), is to allow a creditcardholder to execute secure and anonymous credit card transactions onand off the Internet in accordance with the teachings of U.S. Pat. No.5,956,699. This can be done in a system and in methodology in whichmerchants no longer have access to the cardholders real name, addressand the actual valid credit card number. Such an effectual personalencryption does not, however, prevent the additional use of an Internetstandard encryption such as SSL or SET for online data exchanges. Thelatter will simply make such online transactions even more secured.

For purposes of clarification and illustration, an example of anapplication that uses the methodology taught in U.S. Pat. No. 5,956,699is presented here. Assume that the valid credit card number (VCCN) andthe PIN number are, respectively: VCCN=4678 0123 4567 8012 1200 PIN=2468

Next, assume that the application uses an algorithm that first deletesfour (4) digits from the VCCN and then inserts in their place the PINaccording to the insertion sequence indicated by a so-called PINSequence Insertion Number (PSIN) in order to come up with the scrambledAnonymous Credit Card Number (ACCN), also containing 20 digits. The4-digit PSIN number can either be chosen by the cardholder or assignedby the issuer. Let us assume for this example that the cardholder's PSINis 1357.

Next, assume that the algorithm only operates on digits 5 through 6 ofthe VCCN. This takes into account the fact that the first 4 digits ofthe standard VCCN denote the identification of the credit card issuerand the last 4 digits of the standard VCCN are reserved for theexpiration date, all of which should be left undisturbed. Thus, it isthe middle 12 digits that indicate the account number for the cardholderof the VCCN. Therefore, the algorithm calls for the cardholder to firstdelete the last four digits of the 12-digit account number. In thisexample the 4 digits to be deleted will be “8012”. The 8-digit numberbefore the cardholder PIN is inserted according to the cardholders PSINis “0123 4567”.

Now the algorithm defines the numbering convention of the digitpositions in the ACCN. The first digit position is defined as the zeroth(0.sup.th) and the second is the first (1.sup.st) etc. Thus, accordingto the PISN 1357, the PIN 2468 should be inserted to form the ACCN asfollows: ACCN=4678 021426384567 1200

The 4 digits of the PIN=2468 occupy, respectively, the 1.sup.st,3.sup.rd, 5.sup.th and 7.sup.th positions (according to PISN=1357) usingthe defined digit position numbering convention. In a simpler algorithmfor inserting the PIN, the PIN number itself can act effectively as thePSIN so that the cardholder does not have to remember two numbers. Usingsuch an algorithm, in the example above, the ACCN will now be: ACCN=4678012243648567 1200

The 4 digits of the PIN=2468 also occupy, respectively the 2.sup.nd,4.sup.th, 6.sup.th and 8.sup.th positions of the ACCN (according to animplicit PSIN=PIN=2468) using the defined digit position numberingconvention.

The applications of the teachings of U.S. Pat. No. 5,956,699 justdescribed can be used in a system that reduces fraud while protectingconsumer privacy through anonymous transactions, on and off theInternet. Such a system has three main components that are provided tocomplete a commercial credit card transaction. First, instead of using avalid credit card number, an ACCN is used. Second, instead of using thecardholder's real name, an alias is used. The alias can be selected bythe cardholder or the issuer of the credit card, but it has to be knownby both. Third, instead of using a cardholder's real address, a “ProxyAgent” is used to conceal the cardholder's actual address and stillcomply with current credit card transaction regulations. In such asystem, the use of a credit card for transactions on the Internet can beanonymous to all except the cardholder and the credit card issuer.

In order to reduce the cost of use of the UACC, and increase the rangeof applications in which it can be used, the UACC should have a magneticstorage medium that can be read by a standard magnetic stripe reader.This means that the magnetic storage medium must be capable of beingread by a standard magnetic stripe reader. It also means that theportion of the UACC containing the magnetic storage medium must be sizedsuch that the magnetic storage medium will work with standard magneticstripe readers. A standard magnetic stripe reader works by passing themagnetic stripe portion of a card, such as a credit card, through themagnetic stripe reader in a swiping motion. Standard magnetic stripereaders have been prevalent in retail stores throughout the UnitedStates for many years.

An especially preferred embodiment of the UACC will now be described ineven greater detail. The especially preferred embodiment uses a standardmicroprocessor having its usual Central Processing Unit (CPU),Read-Only-Memory (ROM), Random-Access-Memory (RAM) and Input-Outputdevices (I/O). There are two types of ROMs in the UACC. The first typeis a standard semiconductor ROM, ROM1, fabricated as part of themicroprocessor. ROM1 stores the microprocessor operating system and alsothe bulk of the methodology software. The second type of ROM, ROM2, is aportion of a magnetic stripe, namely Tracks 1 and 3. ROM2 stores therelevant information about the cardholder such as primary account numberVCCN, name, expiration date, encrypted PIN etc. There are also two typesof RAMs in the UACC. The first type of RAM, RAM1, is a standardsemiconductor RAM as part of the microprocessor and needed for itsnormal operation. The second type of RAM, RAM2, is a portion of amagnetic stripe, namely Track 2. RAM2 temporarily stores the encodedACCN to be read by a standard magnetic stripe reader during a normalcredit card transaction after the cardholder inputs the PIN according tothe PSIN algorithm into the UACC.

The methodology software is installed into ROM1 of the microprocessorduring production. A standard parallel port Input Device serves tointerface a numeric keypad and other functional switches of the UACC tothe microprocessor. The UACC also has two Output Devices. The firstOutput Device is a standard parallel output port of the microprocessorused for interfacing to it a 10- or more character alphanumeric LCDdisplay through a driver for outputting information such as recallingfrom memory alias or typed in PIN verification. It is also used forproduction testing and repair or servicing of the UACC. The secondOutput Device is an integrated circuit (IC) magnetic encoder unit builtinto the UACC so as to encode Track 2 of the magnetic stripe or RAM2,either statically in conjunction with the existing magnetic stripe, ordynamically without the use of the existing magnetic stripe, with thetemporary ACCN information for off the Internet credit cardtransactions. In this especially preferred embodiment of the presentinvention illustrated below, only the static magnetic encoder working inconjunction with the existing magnetic stripe is described in detailed.For those skillful in the art, the dynamic thin film magnetic encoder,working without the use of the existing magnetic stripe, can also beused in the present invention as an alternative embodiment. In apreferred embodiment of the present invention, the UACC also contains abattery cell, ON/OFF and other functional switches to render it a fullyfunctional and self-contained credit card (see FIG. 1).

The UACC bridges the old economy world of brick and mortar to the neweconomy world of the Internet. The integrated circuit (IC) magneticencoder with current-carrying conductive writing heads is fabricated ona flexible and ultra-thin polymer (e.g. polyimide) printed circuit board(PCB) intimately in contact with the magnetic stripe located above fordata impression. The encoder driver and digital logic chips are alsomounted on the flexible PCB, but in different areas to form the completeIC magnetic encoder. The IC magnetic encoder is technically compatiblewith conventional magnetic data transfer methodology and makes possiblethe fabrication of the present UACC with physical dimensions exactlylike those for a regular magnetic stripe portion of a credit card.

When the UACC is used in a retail transaction, by merely entering one'sown PIN into the UACC prior to giving it to the merchant for swiping thecredit card transaction, one takes full advantage of the secure andanonymous transaction afforded by the UACC. The user can first check hisor her alias and entered PIN (note that the PIN is never stored in theUACC) using the LCD display on the UACC before the UACC is handed itover to the merchant. Since the cardholder has in effect already signedthe transaction with a digital signature (his or her PIN), no additionalhand signature is required to complete the transaction. The merchantonly need receive the PIN-modified anonymous credit card number (ACCN)and the users alias. The ACCN and the alias are read by a conventionalmagnetic stripe reader and are processed in exactly the same fashion asa conventional credit card number and credit cardholder name since suchinformation can be sent to a credit card approval agent for approval ofthe transaction. The credit card approval agent has all of theinformation necessary to determine if the transaction is valid orfraudulent. The identity of the entity who authorized the credit card,as well as it expiration date, is available in the ACCN in just the samemanner as it is available in a conventional credit card transaction. Thecard number is verified by confirming the card number contained in theACCN as valid for the alias.

To use the UACC for Internet transactions, a cardholder first enters thePIN into the UACC exactly like that for off the Internet transactions.Next, the cardholder continues the transaction using only thecardholder's alias, the ACCN appearing in the LCD display and also thecardholder's choice of trusted delivery (optional) should the cardholderprefer to make this transaction completely anonymous. Thus, by carryingjust one UACC which looks and feels exactly like a regular magneticstripe credit card, one is now able to make old world credit cardtransactions like one always has done in the past. But, moreimportantly, one can now use the same UACC for making secure andanonymous transactions, anywhere in the world, and for both on and offthe Internet transactions.

The especially preferred embodiment of a UACC will now be described ineven greater detail by reference to FIGS. 1 through 3.

FIG. 1 shows the physical layout for an especially preferred embodimentof the Universal Anonymous Credit Card (UACC) 1. The areal dimensions ofthe UACC 1 are 3.375″.times.2.125″ or exactly those of a regularmagnetic stripe credit card in use in electronic commerce today. Thethickness of the UACC 1 varies from .about.0.030″ at the top where themagnetic stripe resides to 0.030″-0.060″ for the rest of the carddependent upon the thickness of the LCD used (see FIG. 1). Besides theON/OFF switch 3, the front side 2 of this UACC 1 has five (5) morefunctional switches, 4-8, labeled and defined as follows: ATM (switch4)=Reserved for Automatic Teller Machine (ATM) card ACC (switch5)=Reserved for Anonymous Credit Card (ACC or A-Card) IC (switch6)=Reserved for Internet Type II Cash MC (switch 7)=Reserved forstandard Magnetic Stripe Credit Card BC (switch 8)=Reserved for A-Cardtransactions using bar codes.

In addition to the switches 3-8, there is a 12-character keypad 9. Theprimary function of the keypad 9 is for the cardholder to enter the PINinto the UACC 1 for generating the ACCN for on and off Internet commercetransactions. There is also a 10- or more character alphanumeric liquidcrystal display (LCD) 10 on the front side 2 of the UACC 1. This LCD 10displays the alias and the ACCN for use for Internet commercetransactions or the alias and bar code representing the ACCN after thecardholder's PIN is entered. The display of the ACCN will automaticallyerase itself after about 2 minutes to avoid exposing significantinformation to third parties.

At the top of the back side 11 of UACC 1 is a standard 3-track magneticstripe 12 found in every common magnetic stripe credit card in usetoday. Track-113 and track-314 are used to store the relevantinformation about the cardholder such as primary account number VCCN,name, expiration date, encrypted PIN etc. Track-215 of the magneticstripe 12 normally contains only the cardholders VCCN to be read by amagnetic stripe reader at the merchant's site. For the present UACCdevice, the ACCN, instead of the VCCN, will be generated on command byentering the PIN with the appropriate function switch “MC” 7 by aspecial encoder 16 located at a designated location underneath themagnetic strip 12. As will be explained in more detail below, thegenerated ACCN which resides temporarily on Track-215 of the magneticstripe 12 will disappear automatically 2 minutes after it is beinggenerated. This is to ensure that no significant information about thecredit card account stays long enough for fraudsters to steal forcommitting subsequent credit card frauds.

The system block diagram for the especially preferred embodiment of thepresent invention is shown in FIG. 2. At the center of the system is aconventional 16-bit microprocessor 16 comprising a Central ProcessingUnit (CPU) 17, a Read-Only-Memory (ROM1) 18, a Random Access Memory(RAM1) 19, a 16-bit parallel Input Port (Input) 20 and a 16-bit parallelOutput Port (Output) 21. The microprocessor 16 receives inputs throughInput 20 from a bank of functional switches 22, which contains switches4 through 8. The microprocessor also receives inputs from a 12-characterkeypad 9 through Input 20. Outputs from the microprocessor 16 emanatefrom Output 21 through a LCD display driver 23 to reach the 10- or morecharacter alphanumeric LCD display 10 and also through an encoder driver24 to reach a designated location of Track-215 of the magnetic stripe12. Such a designated location of Track-215, where the encoder 25 ispositioned, serves as a second RAM, RAM2, for the microprocessor 16.RAM2 stores the encoded ACCN needed for offline credit card transactionsto be read by the merchant's standard decoding equipment very much likea conventional magnetic stripe credit card.

The software program for implementing the methodology provided by U.S.Pat. No. 5,956,699 for the cardholder to execute secured and anonymouscredit card transactions on and off the Internet is installed intoROM118 of the microprocessor 16 during production of the current UACCunit. Information pertaining to the cardholder is encoded onto Track-113and Track-314 of the magnetic stripe 12 which serves as an independentROM, ROM2, for the UACC unit. Since information stored in ROM2 will beread with a standard magnetic stripe reader, it operates independentlyof the microprocessor 16. A battery supply 26 with contacts 27,controlled by the ON/OFF switch 3, completes the UACC system. Thebattery supply provides power to all the components of the UACC system,including the microprocessor 16, LCD display driver 23, encoder driver24, LCD display 10 and the keypad 9.

FIG. 3 shows the physical layout and construction for the especiallypreferred embodiment of the present UACC device. All the electroniccomponents of the system, namely the microprocessor 16, the LCD display10, the keypad 9, LCD display driver 23, encoder driver 24, encoder 25,functional switches 4-8, ON/OFF switch 3 and battery contacts 27 withbattery cell 26, are fabricated on a flexible multi-layered printedcircuit board 28. The flexible printed circuit board 28 with all theloaded components is then encapsulated in plastic into thin 29 and thick30 parallel sections as shown in FIG. 3. The thickness of the thinsection 29 where the conventional magnet stripe 12 will be fabricated ontop of the encoder 25 (to be explained in more detail below) on thebackside is about 0.030″, the same thickness as the magnetic stripecredit cards in use today. The plastic encapsulated thick section 30(see FIG. 3), while holding the fully-loaded flexible printed circuitboard 28 in place, allows the ON/OFF switch 3, functional switches 4-8and the keypad 9 to be physically accessible (e.g. by fingers) from thefront side of the UACC device. The LCD display 10 is also directlyvisible from the front side. Note that the thickness of the plasticencapsulated section would also be 0.030″ thick if a polymer-backed(e.g. Mylar®) ultra-thin LCD display (0.020″ thick typical) is used.

A much simplified theory on magnetic stripe technology, especially onhow to encode (write) and decode (read) digital data respectively on andoff a magnetic stripe used in ordinary credit cards of today, will nowbe provided in order to better explain how an encoder can be fabricatedand work. A magnetic stripe is made out of a thin layer of very tinyferromagnetic particles (typically 0.5 micron long) bound together withresin and subjected to a very strong magnetizing magnetic field (knownas “coercivity”) when such a stripe is printed onto a substrate. Whenthe resin is cured or set, these tiny “magnets” are magnetically andpermanently aligned (magnetized) into a series of South-North magneticdomains forming a chain of S-N, S-N . . . interfaces. The adjacent N-Smagnetic fluxes of these magnetic domains are normally linked togetherfor the entire magnetic stripe to act like a single magnet with Southand North poles at its ends. In other words, an un-encoded magneticstripe is actually a series of aligned South-North magnetic domains (seeFIG. 4).

If a N-N interface (instead of the normal N-S interface for un-encodedmagnetic domains) is created somewhere on the stripe, the magneticfluxes at the N-N interface will repel each other, resulting in aconcentration or increase of flux lines around the N-N interface calleda “flux reversal”. The same situation exists for a S-S interface ascompared with a normal N-S interface. Such a situation will take placeif a strong magnetizing magnet 31 having an opposite magneticorientation, namely N-S, is suddenly introduced on top of one of the S-Nmagnetic domains 32 of the magnetic stripe as shown in FIG. 5. Themagnetic domain 32 will realign its magnetization as that of the strongmagnet on top of it, namely N-S. Under this situation, two fluxreversals have taken place, as illustrated in FIG. 6.

The process of encoding or writing involves the creation of N-N and S-Smagnetic domain interfaces, or flux reversals, and the process ofdecoding or reading that of detecting them. Knowing that magnetic fluxlines always emanate from the North pole and terminate on the Southpole, a sudden introduction of a strong magnetic field (greater than thecoercivity of the magnetic domains) having a N-S magnetic orientationcan magnetize a normal S-N magnetic domain into N-S orientation,resulting in the creation of a pair of flux reversals S-S and N-N, muchlike that shown in FIG. 6 above.

Before proceeding to explain how the encoder of the especially preferredembodiment writes the ACCN on Track-215 of the magnetic stripe 12, it ishelpful to delve deeper into the data storage mechanics of the magneticstripe 12 itself. As stated earlier, the magnetic stripe 12 has threetracks, namely Track-113, Track-215 and Track-314. Digital data arestored in these three tracks according to the American NationalStandards Institute (ANSI) and International Standards Organization(ISO) BCD (5-bit Binary Coded Decimal Format) or ALPHA (alphanumeric)standards. The ANSI/ISO standards for Tracks 1, 2 and 3 are summarizedin Table I as follows:

TABLE I ANSI/ISO Track 1, 2, 3 Standards Track Name Density FormatCharacters Function 1 IATA 210 bpi ALPHA 79 Read Name & Account 2 ABA 75 bpi BCD 40 Read Account 3 THRIFT 210 bpi BCD 107 Read Account &Encode

Track-1 13, named after the “International Air Transport Association”(IATA), contains the cardholders name as well as account and otherdiscretionary data. Track-2 15, “American Banking Association” (ABA), isthe most commonly used. This is the track that is read by ATMs andcredit card checkers. The ABA designed the specifications of this trackand it is believed all major world banks abide by it. It contains thecardholders account number, encrypted PIN, plus other discretionarydata. Track-3 14 is unique and intended to have data read from andwritten on it. At present, it is an orphaned standard and has not beenwidely used to date.

Before the encoder can write on command the ACCN on Track-2 15 of themagnetic stripe, attention must be paid to the data layout for Track-215. Encoding protocol specifies that each track must begin and end witha length of all Zero bits, called CLOCKING BITS. These are used tosynchronize the self-clocking feature of bi-phase decoding, an industrystandard. A typical Track-2 layout is shown as follows:

0000000000000000; 1111222233334444=9912****000000XXXX0000? The symbol“;” after the “0's” is the “START SENTINEL” according to the BCD dataformat. The 4 digits “1111” following is the issuer or acquiring bank'sidentification number. The 12 digits following is the cardholder'saccount number. The symbol following is the “FIELD SEPARATOR” accordingto BCD data format. The 4 digits “9912” following is the expirationdate. The four characters following “****” are data reserved for privateuse. The data length “XXXX” after the string of 0's may vary and is theencrypted PIN offset. Finally the symbol “?” after another string of 0'sis “END SENTINEL”.

The location of the 12 digits that need to be encoded or written oncommand is represented by “2222 33334444” on Track-215 of the magneticstripe 12 in the example cited above.

Next, it is helpful to have an understanding of how the 12 digits arerepresented in BCD data format on Track-215 of the magnetic stripe 12.According to the BCD data format, each decimal digit is coded by 5 bits.The ANSI/ISO BCD Data Format is reproduced in Table II below. Note thatall 21 digits, including the field separator, namely“1111222233334444=9912”, can also be encoded on command if so desired.

TABLE 2 ANSI/ISO BCD Data Format Data Bits Parity b1 b2 b3 b4 b5Character¹ Function 0 0 0 0 1 0 (0 H) Data 1 0 0 0 0 1 (1 H) Data 0 1 00 0 2 (2 H) Data 1 1 0 0 1 3 (3 H) Data 0 0 1 0 0 4 (4 H) Data 1 0 1 0 15 (5 H) Data 0 1 1 0 1 6 (6 H) Data 1 1 1 0 0 7 (7 H) Data 0 0 0 1 0 8(8 H) Data 1 0 0 1 1 9 (9 H) Data 0 1 0 1 1 : (AH) Control 1 1 0 1 0 ;(BH) Start Sentinel 0 0 1 1 1 < (CH) Control 1 0 1 1 0 = (DH) FieldSeparator 0 1 1 1 0 > (EH) Control 1 1 1 1 1 ? (FH) End Sentinel¹Hexadecimal conversions of the data bits are given in parentheses (xH).

How BCD data is actually encoded onto Track-215 of the magnetic stripe12 can now be explained. Table I above notes that Track-2 has a densityof 75 bits per inch (bpi). According to the ANSI/ISO BCD data format,each character is represented by 5 bits. Thus, if the encoder needs toencode 12 digits (see “222233334444” in example above), it will requirea total of 60 bits. Since the density is 75 bpi, the maximum physicalspace available for a stationary encoder head is 0.800″. But theimportant dimension for the design of the encoder head is the spaceavailable for each BCD bit. In the present case, the bit dimension is1,000 mils/75 bits or 13.33 mils (0.0133″) per bit.

At this point, it is useful to explain with the help of FIGS. 7 A-D, howa single character or decimal digit comprising 5 bits in the ANSI/ISOBCD data format is encoded onto Track-215 of the magnetic stripe 12.FIG. 7A shows an un-encoded strip of Track-2 long enough to accommodate5 bits of data. The physical length of this strip is 5.times.0.0133″ or0.0667″ (66.65 mils). This un-encoded strip is divided into fivesegments, each representing a single bit, and each is furtherrepresented by two magnetic domains as shown in FIG. 7A. In accordancewith the industry standard of encoding called Aiken Biphase, or “twofrequency coherent-phase encoding”, data is encoded in “bit cells”defined above and the frequency of which is the frequency of the ‘0’signals. ‘1’ signals are exactly twice the frequency of the ‘0’ signals.So, at least from the conventional way of decoding, the actual frequencyof the data passing the ‘READ’ head will vary with the swipe speed, forthe data density, control functions etc., the ‘0’ frequency, however,will always be twice the ‘0’ frequency. This is illustrated in FIG. 7Bwhere the representation of all ‘1s’, all ‘0s’ and how ‘1’ and ‘0’ dataexist side by side. Note that in FIG. 7B, the bit cell waveforms for ‘0’and ‘1’ are the results of creating the so-called flux reversals of“N-N” or “S-S” at the magnetic domains interfaces of the un-encodedstrip. For the stationary encoder of the present preferred embodiment,the encoding must be consistent with the Aiken Biphase conventionbecause the same ‘READ’ heads will be used to decode the Track-2 datatemporarily stored in UACC devices during offline (off the Internet)credit card transactions.

Consistent with the Aiken Biphase convention therefore, FIG. 7C shows,as an illustration, how BCD decimal digits ‘0’, ‘5’ and ‘9’ would appearreferenced to the un-encoded 5-bit strip of FIG. 7A. Also shown in FIG.7C are the orientation of the magnetic domains and the flux reversals atthe domain interfaces. Thus, if an encoder head of the present preferredembodiment is designed to be on top of the 10 magnetic domainsrepresenting the 5-bit decimal digit, it would be possible to magnetizeon command the individual domains in order to create the appropriateflux reversals corresponding to the desired decimal digit. This isillustrated in FIG. 7D. The orientation of the magnetic domain 33 whenun-coded is S-N as shown in FIG. 7D. The two contact bits 34 and 35control which direction the magnetizing current is flowing. When 34 and35 are suddenly made “1” and “1”, current I+ will flow in from contact34 to ground resulting in flipping the orientation of magnetic domain 33to N-S. Meanwhile the current I− from “+V” to contact 35 is zero. Whencontact 34 and 35 are suddenly left open circuited, both I+ and I− arezero and the orientation of magnetic domain 33 will stay as N-S. Whencontacts 34 and 35 are suddenly changed to “0” and “0”, current I− willflow from “+V” to contact 35 and cause the magnetic domain to revertback to S-N while I+ is zero. No domain flipping occurs if the bits forcontacts 34 and 35 are either “1” “0” or “0” “1”. In the former case,the magnetizing effect of I+ is neutralized by I−. Both I+ and I− arezero for the latter case. The magnitudes of currents I+ and I− needed toflip the magnetic domains with coercity of the order of 300-500 gausses(“soft” magnetic stripe found in conventional credit cards) for currentcarrying conductor of 1-2 microns thick are several hundredmilliamperes. The electrical power required to encode or decode 12decimal digits is of the order of tens microwatts.

In order to encode in the present example a total of 12 decimal digits,one would need to encode 5.times.12 or 60 bits of data. As shown in FIG.7D, the encoder has to have two micro-heads per bit of data.Furthermore, each micro-head has a PLUS or MINUS polarity. If thepolarity is PLUS, current will flow in one direction so as to generate aN-S magnetizing magnet. Similarly, if the polarity is MINUS, currentwill flow in the opposite direction so as to generate a S-N magnetizingmagnet. So the encoder of the present preferred embodiment will have2.times.60 micro-heads each with a PLUS and MINUS polarity. Anespecially preferred embodiment of the encoder with the driverelectronics and logic is shown schematically in FIG. 8.

FIG. 8 shows the 12 decimal digits divided up into 60 bit cells witheach bit cell comprising two magnetic domains and each having a PLUS andMINUS polarity. There are therefore a total of 120 magnetic domains thathave to be addressed, each with two polarities, making it a total of 240address lines as shown in FIG. 8. These addresses lines are accessed inbunches of 10 (5 magnetic domains or 21/2 bit cells). The addressoriginates from using 10 bits of the 16-bit Output port 21 (see FIG. 2of system block diagram for UACC) and then through the encoder driver 24(also see FIG. 2) as current buffer before being connected to the 24bunches of 10 address lines. Each of the 24 bunches of 10 address linesis accessed with a 32:1 decoder using five of the 16 bits of the Outputparallel port 21. The decoder selects one of the 24 bunches of 10address lines via switch bank 36 (there is a total of 24 switch bankssimilar to switch bank 36) comprising 10 switches each. In essence, itis the switch bank that selects which of the 10 address lines out of the24 bunches that are being connected to the output of the encoder driver24. Thus, it is possible to encode the 12 decimal digits into adesignated location of Track-215 of the magnetic stripe with commandsfrom the microprocessor and outputted through the parallel port 21through the encoder driver 24. Such a software command is part of themethodology algorithm taught in U.S. Pat. No. 5,956,699 and stored inROM1 (see FIG. 2) of the microprocessor 16. The stored algorithmgenerates the ACCN or, in essence, a “Coupon” (Customer's one-timeunique purchase order number), from the valid credit card number VCCNand the cardholders PIN when inserted properly into part of the VCCN.

The manner in which the Universal Anonymous Credit Card (UACC) will workunder different on and offline transaction circumstances will now bedescribed. It is first assumed that the cardholder has opened an UACCaccount with an issuer or acquiring bank. The cardholder has turned overa real name, address, personal and financial information to the issuer.In return, the cardholder is assigned a valid credit card number, VCCN,a credit limit, an Alias (chosen by the cardholder) and a proxy agent,and most importantly a cardholder UACC. The issuer has to assign thecardholder a proxy agent to use instead of giving out the cardholdersaddress in order to comply with the existing credit card transactionregulation. After obtaining a UACC from the issuer, the cardholder isnow free to do anything and everything on and off the Internet safelywith full assurance that nobody will find out what, where, when and howmoney is being spent with the UACC card, except its issuer.

The manner in which the cardholder can use his or her UACC to shop onthe Internet will now be described. It is possible that not every onlinemerchant will accept the UACC in the beginning, so the cardholder mayhave to identify those merchants that are partners with the UACC issuerbank. Otherwise, the transactions with the UACC will not be processedproperly by the existing infrastructure that processes only conventionalcredit cards. Suppose the cardholder now wishes to purchase somemerchandise from an online merchant who accepts UACC. All the cardholderhas to send to the merchant's Web site online is his or her alias, aproxy agent's name assigned to the cardholder by the issuer bank, theACCN or anonymous credit card number which will be obtained from theUACC (to be explained below), the merchandise and shipment choice. Thisis completely different from what the cardholder normally has to giveout, viz. a real name, address and the valid credit card number, shouldthe cardholder use a regular credit card. To obtain the ACCN from hisUACC device, all the cardholder has to do is to first push the button“CC”, which is reserved for Anonymous Credit Card transactions, then toenter the cardholder's PIN using the keypad and then the “#” key. In theLCD display, the alias will first be scrolled across the displayfollowed by the 10-digit ACCN. Note that the first six digits (fourdigits are used to identify the issuer bank and two more digits todesignate a specific BIN number) and the last four digits of the ACCNalways remain the same as those in the VCCN which signifies the issuersidentification and credit card BIN number, and the expiration daterespectively. The cardholder can then use this ACCN to complete thetransaction with the online merchant. After the cardholder finishesusing the ACCN, he or she can either erase it from the LCD display bypressing “*” followed by “#” in the keypad, otherwise the ACCN willdisappear from the LCD display automatically after approximately 2minutes.

As one can see from this transaction on the Internet using the UACC, thereal name and address of the cardholder, including the credit cardnumber itself, never appear on the Internet or even are made known tothe merchant. Even though the ACCN or Coupon does appear, together withthe alias of the cardholder, across the Internet during the onlinetransaction, this ACCN or Coupon number does not stay the same,according to the methodology of U.S. Pat. No. 5,956,699, but changesautomatically after every transaction or use. Thus, unlike all the othercredit card transactions on the Internet today, no valid credit cardnumbers are actually available in transmission for theft by anybody.Only the ACCN or Coupon number will appear on any or all transactionrecords and that number is useless for any subsequent transactionsbecause it is time variant.

For off the Internet transactions, the UACC behaves just like anordinary credit card. The only difference is that before one hands overthe UACC to the merchant for charging the amount, one enters one's PINafter pushing first the “MC” button on the UACC device, which isreserved for magnetic stripe credit card transactions, and then followsit with a “#” key on the keypad. It is assumed here that the cardholderis satisfied with what is being charged on the credit card before thecardholder, in effect, “signs” it digitally in the transaction. Unlikeordinary magnetic stripe credit cards of today, no personal handsignature is needed for off the Internet transactions with the UACC. Byentering the PIN, the UACC automatically encodes temporarily the ACCNonto Track-2 of the magnetic stripe 12. The use of the resultant ACCN orCoupon is likened to the cardholder already signing the credit card witha personal digital signature for the transaction. The rest of thetransaction simply follows that of a regular magnetic stripe credit cardwith the existing credit card processing infrastructure.

Thus, there has been described a Universal Anonymous Credit Card (UACC)device that is capable of allowing the cardholder to execute on and offthe Internet secure and anonymous credit card transactions. The UACC canbe used in methods for implementing an anonymous credit card transactionbetween a user and a merchant as is described in U.S. Ser. No.09/619,859. An embodiment of such a method is set forth in FIG. 9. Inaccordance with this embodiment, a user must first establish a useraccount with a credit source. The credit source may be a bank, a creditcard company or any other institution involved with issuance of creditcards or bank debit cards, such as a credit union or other institution,or a money source as described in U.S. Pat. No. 5,913,203. When the userestablishes a user account with the credit source, one or more usersettlement mechanisms through which the user can pay the credit sourcefor charges and fees billed to the user account will be established. Forexample, in the case of credit card transactions, the user and thecredit source will enter into an agreement concerning use of the creditcard. As a further example, in the case of debit or electronic checkingservices, the user and credit source may enter into a separate agreementconcerning how and from what account such debits will be debited.

After a user account is established, the credit source will create oneor more user account records associated with the user account to containa variety of information, including a user account number, a fictitiousaccount name, a “Proxy Agent,” a user key and, when applicable, a userinsertion key. The fictitious account name can be selected by thecardholder or the issuer of the credit card, but it has to be known byboth. The “Proxy Agent” is used to conceal the cardholder's actualaddress and still comply with current credit card transactionregulations—in other words, it is a fictitious address. Additionalinformation that might typically be contained within such recordsincludes cross references to other accounts, the user's name and theuser's billing address. An electronic card, such as the UACC card, usesan algorithm to generate a valid personal charge number.

When the electronic card is used in a retail transaction, by merelyentering one's own PIN into the electronic card prior to giving it tothe merchant for swiping the credit card transaction, one takes fulladvantage of the secure and anonymous transaction afforded by theelectronic card. The user can first check his or her alias and enteredPIN (note that the PIN is never stored in the electronic card) using thekeypad on the electronic card before the electronic card is handed itover to the merchant. Since the cardholder has in effect already signedthe transaction with a digital signature (his or her PIN), no additionalhand signature is required to complete the transaction. The merchantonly need receive the PIN-modified anonymous credit card number (ACCN)and the user's alias. The ACCN and the alias are read by a conventionalmagnetic stripe reader and are processed in exactly the same fashion asa conventional credit card number and credit cardholder name since suchinformation can be sent to a credit card approval agent for approval ofthe transaction. The credit card approval agent has all of theInformation necessary to determine if the transaction is valid orfraudulent. The identity of the entity who authorized the credit card,as well as It expiration date, is available in the ACCN in just the samemanner as it is available in a conventional credit card transaction. Thecard number is verified by confirming the card number contained in theACCN as valid for the alias.

To use the electronic card for Internet transactions, a cardholder firstenters the PIN into the electronic card exactly like that for off theInternet transactions. Next, the cardholder continues the transactionusing only the cardholders alias, the ACCN appearing in the LCD displayand also the cardholders choice of trusted delivery or Proxy Agent(optional) should the cardholder prefer to make this transactioncompletely anonymous. Thus, by carrying just one electronic card whichlooks and feels exactly like a regular magnetic stripe credit card, oneis now able to make old world credit card transactions like one alwayshas done in the past. But, more importantly, one can now use the sameelectronic card for making secure and anonymous transactions, anywherein the world, and for both on and off the Internet transactions.

As is apparent from the foregoing description, the real name and addressof the cardholder, including the credit card number itself, never needappear on the Internet or even need to be made known to the merchant.Even though the ACCN or Coupon (Customer One-time Unique Purchase OrderNumber) does appear, together with the alias of the cardholder, acrossthe Internet during the online transaction, this ACCN or Coupon numberdoes not stay the same, according to the methodology of U.S. Pat. No.5,956,699, but changes automatically after every transaction or use.Thus, unlike all the other credit card transactions on the Internettoday, no valid credit card numbers are actually available intransmission for theft by anybody. Only the ACCN or Coupon number willappear on any or all transaction records and that number is useless forany subsequent transactions because it is time variant.

Accordingly, this disclosure includes the following methods.

Method 1. A method for implementing an anonymous Mail Order TelephoneOrder (“MOTO”) credit card transaction between a user and a merchant,comprising the steps of:

establishing a user account between a credit source and the user whichis associated with a fictitious account name, a user account number, auser key and a user settlement mechanism through which the user can paythe credit source for charges and fees billed to the user account;

providing the user with an electronic card that is comprised of:

a card base;

a storage medium affixed to the card that can be read by a card readerbut is not readable by a human eye;

a computer affixed to the card;

an input mechanism for providing input to the computer;

a display controlled by the computer; and

a power source for supplying power to the computer;

wherein the electronic card has a fictitious account name stored in amemory device accessible by the computer, the computer is capable ofcausing data to be stored in the storage medium and the electronic cardis sized such that a standard magnetic stripe reader can read themagnetic storage medium;

completing a MOTO credit card transaction between the user and themerchant in which the user is charged a monetary value by the merchant,comprising the following steps:

entering the user key into the input mechanism;

executing an algorithm by the computer that uses the user key and a cardnumber stored in the electronic card as input variables to generate avalid personal charge number;

visually reading the valid personal charge number from the display;

providing the valid personal charge number and the fictitious accountname to the merchant;

sending the monetary value, the valid personal charge number and thefictitious account name to a credit approval center that verifies thatthe valid personal charge number is valid for the fictitious accountname and approves the MOTO credit card transaction; and

sending an approval of the transaction from the credit approval centerto the merchant.

Method 2. Method 1 wherein the MOTO credit card transaction is conductedbetween the user and the merchant over a computer network.

Method 3. Method 1 and the further steps of:

establishing a user insertion key that is associated with the useraccount; and

generating the valid personal charge number from the card number byinserting the user key into the card number through use of the userinsertion key and a permutation variable.

Method 4. Method 3 and the further steps of:

changing the permutation variable from an initial state to a differentstate; and

generating a second valid personal charge number from the card number byinserting the user key into the card number through use of the userinsertion key and the permutation variable in the different state.

One particular method that can be used to generate a one-time paymentcard number, which is described in U.S. application Ser. No. 09/659,434,will now be discussed.

The present disclosure is adapted for use in many kinds of financialtransactions. For example, it can be used in credit card transactions,bank or debit card transactions, or electronic script transactions.Because of the versatility of this embodiment, it can be used inconnection with a wide variety of instruments that can be used inconnection with such financial transactions. Thus, it can be used withelectronic cards, software programs used in network applications, ortelephones (especially telephones used in what is now being referred toas m-commerce, or mobile commerce). Moreover, it can be used whethersuch transactions are conducted in person, face-to-face, or whether suchtransactions are conducted by an indirect medium, such as a mail ordertransaction, a transaction conducted over a computer network (forexample, the Internet), or a telephone transaction.

As is the case in most financial transactions, three parties aretypically involved in completed financial transactions according to thepresent invention. A party makes a monetary payment. In the context ofthe following description, this is the first entity or customer. Anotherparty receives the monetary payment, and this party can be a singleparty or two or more parties. In the context of the followingdescription, the party or parties that are receiving the monetarypayment are referred to as the second entity. Finally, there is at leastone party, and usually multiple parties, that serve as intermediaries toallow the customer to transfer monetary value to the second entity. Theintermediary group of one or more parties will be referred to in thecontext of the following description as a money source. Thus, the moneysource may be one or more banks, a credit card company or any otherinstitution involved with issuance of credit cards or bank debit cards,such as a credit union or other institution, or a money source asdescribed in U.S. Pat. No. 5,913,203 which states, in col. 5, lines6-17: “Initially, there must be a money source. This is described as apseudo cash repository, but it does not need to be a single entity. Inpractice, it can be a single bank, or a single credit card company or anumber of affiliated banks (a bank group) or a number of affiliatedcredit card companies (a card group) affiliated with one or moremerchants and set up to do business with one or more money sourcecustomers or some other entity or entities that will perform such afunction. The pseudo cash repository, in concept, is similar to anentity that issues travelers checks (for a non-anonymous cash-liketransaction) or a money order (for a potentially anonymous cash-liketransaction).” U.S. Pat. No. 5,913,203 further states, in col. 6, lines34-41: “The pseudo cash repository maintains a record of the pseudo cashunit and the fixed monetary value associated with the pseudo cash unitand, in an especially preferred embodiment, can be either a computer ora network of computers that operates as the money source. If the pseudocash repository relies upon a network of computers, the network can bededicated or it can be connected by an encrypted two-way communicationlinkage.”

In connection with this embodiment, it is not necessary that the firstentity use a real identity, although such an option is also acceptable.Instead, a pseudonym, such as a screen name or an alias, could be usedto protect the first entity's privacy and provide additional security.

Although the first entity need not use a real identity, the first entitymust establish an account with a money source. When the account isestablished, the first entity and the money source must agree upon apayment mechanism or protocol. In the case of a credit card or a bankcard, this could be done in the same fashion as exists today, and thefirst entity could select a fictitious account name as is explained ingreater detail in co-pending U.S. patent application Ser. No.09/619,859. It is especially preferred that two different users not beallowed to select the same fictitious account name so that a fictitiousaccount name also represents a unique identifier. However, the preferredembodiment could also be used in connection with a prepaid account. Insuch a scenario, the first entity could simply purchase a prepaid cardand no real identity would ever be required.

When the first entity establishes an account with the money source, auser key must be selected. The user key can be a Personal IdentificationNumber, or “PIN,” similar to that which is currently in widespread usein the United States in connection with automated teller machines. Boththe first entity and the money source must have access to the user key,which can be selected by either entity. In order to be able to retrievethis user key, the money source must create a record associated with thefirst entity that includes the user key and a first entity identifier(whether this be the real name of the first entity or a fictitiousaccount name).

Once the first entity has established an account with the money sourceand a user key has been selected, the first entity must be supplied withthe means to generate a customer one-time unique purchase order number(“Coupon”). As already described, this could be hardware or software,but, in either case, it will include a customer random number generatorand a customer permutation variable that is correlated with a customersequence number.

There is some debate, within the mathematical and cryptographiccommunities, as to what constitutes a “random number generator.” Attimes, the term is used somewhat loosely, and sometimes it is used torefer to what is also commonly referred to as a “pseudo random numbergenerator. In the context of the present invention, a “random numbergenerator” shall be defined to include a pseudo-random number generator.The details of how a random number generator (or a pseudo-random numbergenerator) works, and how they can be used to generate a series ofrandom (or pseudo-random) numbers, are well known in the art ofcryptography and will not be repeated here. (A general description ofrandom number generators and various pseudo-random number generators,and a discussion of common implementation mistakes that are made whenusing pseudo-random generators, is set forth in ICSA Guide toCryptography (McGraw-Hill 1999), by Randall K. Nichols, at pages 356,399-406, and 702, the disclosure of which is specifically incorporatedherein by reference.)

A person skilled in the art could choose one of many different “randomnumber generators” known in the art for use in connection with thepresent invention, and any number of such devices will suffice, althoughit is probably most desirable, from a security standpoint, to use acryptographic pseudo-random number generator. In an especially preferredembodiment, the “random number generator” is what has been referred toby H. D. Knoble as a “Portable Quasi-Random Number Generator.” Morespecifically, it is especially preferred that the random numbergenerator be an additive three part prime modulus multiplicative linearcongruent random number generator which can be generated by thefollowing algorithm:

RN=INT((R−(INT(R)))×10)

where RN is the random number, INT stands for an Integer function, and Ris calculated as follows:

R=(SA/K4)+(SB/K8)+(SC/K12), where

SA=K1×MOD(SA,K2)−K3×(SA/K2), but if SA is less than zero, SA=SA+K4,

SB=K5×MOD(SB,K6)−K7×(SB/K6), but if SB is less than zero, SB=SB+K8,

SC=K9×MOD(SC,K10)−K11×(SC/K10), but if SC is less than zero, SC=SC+K12,

where SA, SB and SC are seed values, all K numbers are constants, andMOD is a Modulo function. The above-identified algorithm uses threeadditive parts, but an algorithm with additional (or, less preferably,fewer) additive parts could also be used. Additional details concerningModulo and Integer functions can be obtained from VS FORTRAN ApplicationProgramming: Language Reference, Release 2.0, IBM (3rd Ed., September1982), pages 215 and 216, the disclosure of which is specificallyincorporated herein by reference.

The customer random generator is used to generate a sequence of numberswith qualities similar to that of a sequence of truly random numbers. Byusing a pseudo-random number generator, the sequence will be fixed for agiven algorithm, using a given set of constants, starting from a givenseed value. A number in such a sequence can be referenced by itsposition relative to an initial setting, and this shall be referred toas a sequence number. Thus, a string of one hundred numbers generated bya random number generator can be assigned sequence numbers of 1-100,respectively, which means that the fiftieth number in the string wouldbe assigned the sequence number of 50.

Because the money source must also use a random number generator, thecustomer random number generator and the money random number generatormust be synchronized so that they will achieve identical results whenthe customer sequence number and the money source sequence number areidentical. If a money source wants a number of different customers touse the same random number generator but generate different sequences ofnumbers, such results can be obtained several ways. For example,different customers might have different initial seed values, differentcustomers might have one or more different constants, differentcustomers might have a different permutation variable as an initialsetting, or two or more of these options might be employed.

When the first entity wishes to generate a Coupon, the first entityenters the user key into the hardware or software used to generate theCoupon. Once the user key is entered, it is combined with a customerpermutation variable that is correlated with a customer sequence numberto form a customer permutated user key. The combination can be done byany number of mathematical functions (simple examples of which areaddition, subtraction, division and multiplication) or by any suitablealgorithm or set of rules. The customer permutation variable and thecustomer sequence number can be correlated in many different ways, thesimplest example of which is that they are identical. Another example ofa simple correlation would be to vary the permutation variable accordingto a preselected algorithm in accordance with the customer sequencenumber, or through use of the customer sequence number as an input intothe algorithm.

The customer permutated user key and the user insertion key are used asinput variables in an algorithm to form a Coupon. In an especiallypreferred embodiment, the customer permutated user key is inserted intoa user account number. Simple methods of insertion include addition andsubstitution, or a combination of the two. After a Coupon is generated,the customer sequence number is changed, and a new entry of the user keywill result in generation of a new customer permutated user key and anew Coupon. Because generation of the Coupon can be done by a computer(whether it be a “traditional” computer or some other device that can bea host computer or a client computer, such as a chip located in anelectronic card or telephone), for all practical purposes, the Couponcan be generated as soon as the user key is entered into the computer.

Once a Coupon is generated, it can be transferred to a second entity,along with a first identity identifier, to pay for goods or servicesand, in turn, the Coupon and the first identity identifier can betransferred to the money center.

When a customer's user key is entered into an input device, there isalways a possibility of mistake due to human error. Accordingly, it ishighly desirable to provide a mechanism to account for such mistakes.However, the mechanism should be controlled to avoid the possibility ofan unacceptable compromise to security, as could be the case ifunlimited errors in entry of the customer's user key are allowed. Thepreferred embodiment provides a mechanism to satisfy both desires by themethod a Coupon is validated and by allowing the customer random numbergenerator and the money source random number generator to beresynchronized from a first setting to a second setting.

A Coupon is validated when the money source determines that the Couponis valid for the first entity identifier submitted with the Coupon. Inorder to determine what Coupons might be valid for the first entity, themoney source determines what Coupons the first entity will generate, andthe order in which they will be generated. One way that the money sourcecan determine what Coupons will be generated by the first entity is togenerate coupons from the same starting input that would be used by thefirst entity, using the same random number generator. In other words,the money source uses a money source random generator that uses the samealgorithm as the customer random generator (including initial seed(s)and constants), using the same user key. Thus, when the money sourcegenerates a money source Coupon from a money source sequence number thatis identical to a customer sequence number used by a customer togenerate a Coupon, the money source Coupon should be identical to, andthus match, the Coupon. This, in turn, validates the Coupon.

Validation of a Coupon is very simple to implement when the customersequence number and the money source setting are synchronized. The moneysource Coupon could be generated at the time the Coupon is submitted forvalidation, or it could already be generated, and stored, in a look-uptable. However, there are reasons why such synchronization may notexist. For example, a customer might generate a Coupon but, for whateverreason, not use it. Alternatively, a consumer might make a mistake andnot enter the correct user key, and thus generate an invalid Coupon.(Although the latter possibility could be avoided by storing the userkey in the hardware/software and confirming that the user key entered iscorrect, such storage is undesirable since the existence of such arecord compromises security).

In order to account for the possibility that the customer sequencenumber and the money source setting may not be synchronized, validationcan be permitted if the Coupon matches any one of a preselected numberof money source Coupons generated in series by the money source from anexpected starting value of the customer sequence number. (Selection ofthe preselected number is a matter of design choice that involves atradeoff between usability and security, and the number might be changedat different times or for different conditions.) Although such seriescould be generated at the time of submission of a Coupon for validation,it is especially preferred that the series be generated and stored as asequential set that can be queried upon submission of a Coupon forvalidation. Using this methodology, once a Coupon is validated, thematching money source Coupon and all earlier created money sourceCoupons can be deleted from the sequential set. Then, since thesequential set now contains less than the preselected number of Coupons,one or more additional money source Coupons are generated to bring thepopulation of money source Coupons back up to the preselected number (ora newly selected number).

The use of a sequential set of money source Coupons works well as longas Coupons are submitted for verification in correct sequential order.Normally, this should not be a problem. However, there may be instanceswhere this could present a problem, such as use of a Coupon to pay forsomething ordered by mail. In order to account for such a possibility,the money source can store money source Coupons deleted from thesequential set in a recent history file, and this file can be maintainedfor a preselected length of time. Using this methodology, if a matchwith a money source Coupon stored in the sequential set does notvalidate a Coupon, a match with a money source Coupon stored in therecent history file can still validate it. However, the money sourcemight also want to implement additional security measures whenvalidating a Coupon by comparison with the recent history file. Thus, inthe given example of a mail order, the money source might also requirethat the shipping address match an approved shipping address for thefirst entity. Alternatively, the money source might also requireindependent confirmation of the validity of the Coupon by contacting thefirst entity, e.g. by telephone or e-mail, if the value of the Couponexceeds a threshold limit.

If a Coupon is not validated, the money source will reject it asinvalid. The Coupon might be invalid due to error by the first entity,or due to error somewhere during its path of transmission to the moneysource, or due to fraudulent activity. Accordingly, it is highlydesirable not to place a hold on activity by a customer whose firstentity identifier has been used with an invalid Coupon until suchactivity exceeds a threshold level. Once this threshold level has beenexceeded because a preselected number of invalid Coupons are notverified for the first entity, an invalid user account number conditioncan be triggered to prevent any further processing of Coupons submittedwith the first entity identifier until the invalid user account numbercondition is removed.

If a first entity has submitted too many invalid Coupons, or has justgotten too far out of synchronization from the money source (e.g., achild playing with an electronic card), it may be desirable toresynchronize the customer random number generator with the bank randomnumber generator. One easy way to do this is as follows. The firstentity could contact the money source, enter the first entity's userkey, and provide the money source with the resultant Coupon. The moneysource could then use this Coupon to determine what customer sequencenumber was used to generate the Coupon, and reset its recordsaccordingly, as is illustrated in the following example:

Assume that the sequential set maintained by the money source contains10 money source Coupons, that the first entity has previouslysuccessfully submitted Coupons for transactions 1-5, and that the firstentity's customer sequence number is now 25. When the first entitycontacts the money source, the Coupon that it will generate will be the25th Coupon in a string, but the sequential set maintained by the moneysource will only contain the 6th through 15th Coupons. Therefore, themoney source will not generate a match until its 25th money sourceCoupon is generated, at which point the customer random number generatorand the money source random number generator will be resynchronized.Next, the money source will generate money source Coupons 26 through 35and place them in its sequential set of money source Coupons for thefirst entity, and an invalid user account number condition, if set, canbe removed.

Another way that the customer random number generator and the moneysource random number generator can be resynchronized is for the moneysource to provide the first entity with a new seed value to be inputinto the random number generator, but this would require some mechanismto allow such input. In the case of an electronic card, telephone orother hardware device, a special function key, followed by the input,might perform this.

Although the foregoing discussion of the preferred embodiment hasfocused on use of a single Coupon, additional security could be obtainedby requiring use of two or more Coupons for a given transaction,especially if it exceeds a preselected threshold value or if arequirement for additional security is triggered. If two Coupons arerequired to process a given transaction, it is far less likely that arandom guess or person without access to the valid user key andrequisite algorithm could generate a correct sequence of Coupons. Thisfact can also be used to prove fraudulent or unauthorized use, or tocheck for such use. For example, suppose a first entity submits a Couponfor validation in connection with a certain transaction, and itsvalidity is called into question. The first entity could be prompted toprovide one or more additional valid Coupons, and if this could not bedone, it would be a good indication of potential fraud.

In certain types of transactions, such as transactions over theInternet, there is some possibility that a first entity identifier couldbe intercepted and somebody might make fraudulent attempts to guess avalid Coupon for an intercepted first entity identifier without actualpossession of authorized hardware or software that might be used togenerate a valid Coupon. Once again, by requiring use of two or morevalid Coupons, the potential for fraud could be reduced. Alternatively,the first entity could be asked to generate a Coupon using an incorrectuser key. In this scenario, if the first entity does not actually havepossession of the hardware or software to generate a Coupon, it wouldnot be possible for the first entity to generate the Coupon that couldbe generated by the money source through use of the incorrect user key,the money source permutation variable and the money source sequencenumber.

Fraudulent activity might also be detected by the nature of invalidCoupons submitted for verification. When the money source receives aCoupon for verification, it is possible to work backwards from theCoupon to determine what user key and permutation variable were used togenerate the Coupon for a given sequence number. Based upon what userkeys were used in generating invalid Coupons, it might be possible tospot potential fraudulent activity. It is also possible to detect ordeter fraudulent activity, and increase security, if the user key isperiodically changed. This can be done when the first entity and themoney source validly agree to change the user key, and the moneysource's records are changed accordingly (including the money sourceCoupons contained within the sequential set).

Although the foregoing detailed description is illustrative of preferredembodiments of the present invention, it is to be understood thatadditional embodiments thereof will be obvious to those skilled in theart. For example, the same inventive concepts disclosed herein could beused in a system in which a customer has two or more account numbersand/or identities, with the same or different user keys. In the case ofan electronic card or telephone, this would allow the customer to selectwhich account should be used (for example, to choose a business creditcard for use with a business expense, a personal credit card for usewith a personal expense, or a bank card at a local store for groceriesand cash back). Alternatively, a customer might be permitted to usemultiple user keys for the same account number and the same identity.This could allow some of the same functionality, or it could be used toclassify the type or nature of the expense or transaction. Furthermodifications are also possible in alternative embodiments withoutdeparting from the inventive concept.

Accordingly, this disclosure includes the following methods.

Method 1. A method for providing multiple secure transactions between afirst entity and at least one additional entity, comprising the stepsof:(1) generating a customer one-time unique purchase order number(“Coupon”) for the first entity by the following steps:

(a) combining a user key with a customer permutation variable that iscorrelated with a customer sequence number to form a customer permutateduser key;

(b) using a customer random number generator to generate a customer userinsertion key that is correlated with the customer sequence number; and

(c) generating a Coupon from a user account number by inserting thepermutated user key into the user account number in accordance with analgorithm that uses the customer user insertion key;

(2) transferring the Coupon and a first entity identifier to a secondentity;(3) transferring the Coupon and the first entity identifier from thesecond entity to a money source repository;(4) creating a sequential set of the money source repository having apreselected number of money source Coupons for the first entity by thefollowing steps:

(a) combining the user key with a money source permutation variable thatis correlated with a money source sequence number to form a money sourcepermutated user key;

(b) using a money source random number generator to generate a moneysource user insertion key that is correlated with the money sourcesequence number;

(c) generating a money source Coupon from the user account number byinserting the money source permutated user key into the user accountnumber in accordance with the algorithm that uses the money source userinsertion key, wherein the money source Coupon is correlated with themoney source sequence number and stored in the sequential set, saidmoney source Coupon being identical to the Coupon when the customerpermutation variable and the money source permutation variable areidentical;

(d) changing the money source sequence number; and

(e) repeating steps (a) through (d) as needed so that the sequential sethas the preselected number of money source Coupons;

(5) verifying that the Coupon is valid for the first entity byconfirming that it is identical to a matching money source Couponcontained within the sequential set;(6) deleting the matching money source Coupon and all earlier createdmoney source Coupons from the sequential set;(7) changing the customer sequence number; and(8) repeating steps (2) through (7).Method 2. A method as recited in method 1, wherein the second entity iscomprised of a plurality of different entities.Method 3. A method as recited in method 1, wherein the customer randomnumber generator and the money source random number generator areresynchronized from a first setting to a second setting.Method 4. A method as recited in method 1, wherein the customer sequencenumber is changed every time a Coupon is generated.Method 5. A method as recited in method 1, wherein the user key isentered into an input device whose output is used to generate theCoupon.Method 6. A method as recited in method 5, wherein the customer sequencenumber is changed every time the user key is entered into the inputdevice.Method 7. A method as recited in method 1, comprising the followingadditional steps:setting an invalid user account number condition if a preselected numberof Coupons are not verified for the first entity; andterminating step (5) when the invalid user account number condition isset.

The disclosure of U.S. Ser. No. 10/968,401 provides an unprecedentedopportunity to customize use and processing of payment card transactionsthrough use of one or more customization variables.

In the context of this description, a one-time payment card numberrefers to a payment card number of either a credit or a debit card,generated in accordance with the present invention, that is useful infinancial transactions in the same fashion as a traditional payment cardnumber.

Like a traditional payment card number, a one-time payment card numbershould be capable of being read by a standard magnetic stripe readerwhen it is part of a physical card used in traditional face-to-facetransactions in which a user presents the physical card to a merchantfor payment. However, like traditional payment card numbers, a one-timepayment card number should also be capable of being used in a Mail OrderTelephone Order (“MOTO”) credit card transaction between the user and amerchant. Thus, like a traditional payment card number, the one-timepayment card number should fit within, and work with, present platformsand protocols for financial transactions involving payment cards, suchas traditional credit cards. This versatility allows the one-timepayment card number to be used with electronic cards, software programsused in network applications, or telephones (especially telephones usedin what is now being referred to as m-commerce, or mobile commerce).

A traditional payment card number can be characterized as having threeparts. First, there is a set of fixed variables. This contains numeralsthat represent certain specified data fields, such as a bank identifierand a month and year expiration date for a given payment card. (The“bank” may be any “money source” as that term has been defined in U.S.Pat. No. 5,937,394.) Second, there is a set of variable variables. Thiscontains numerals that will vary for different payment cards issued bythe same money source. In other words, this is the portion of the cardnumber that will be specific to an individual entity or account for agiven issuing money source. Third, there is a check sum digit. The valueof the check sum digit is dictated by the other numerals in the cardnumber.

In the context of the present invention, a user one-time payment cardnumber is akin to a traditional payment card number, with certainexceptions. In a traditional payment card number, there might be a setof six fixed variables, followed by a set of nine variable variables,followed by a check sum digit and another set of four fixed variablesrepresenting the month and year. When a user uses this traditionalpayment card number to complete a given financial transaction, thetransaction is always completed by using the same twenty digits for thepayment card number. By contrast, if the user uses a one-time paymentcard number to complete any such given financial transaction, thetransaction will not be completed by always using the same twenty digitsfor the payment card number. Instead, the twenty digits of the one-timepayment card number will vary, and the degree to which they vary maydepend upon user selection of a customization parameter. In addition,because the one-time payment card number varies with successive usage,the check sum digit will not necessarily be the same with successiveusage, although it may be. Thus, the check sum digit must berecalculated for each new one-time payment card number, and this is whyit shall be referred to as a “check sum variable” in the context of aone-time payment card number according to the present invention.

Another difference between a traditional payment card number and aone-time payment card number is the way that a given transaction usingeither number is validated by a verification agency, which may be amoney source or an entity who processes payment card transactions. Whena transaction involving a one-time payment card number is processed, theverification agency must verify that the one-time payment card number isvalid for the user identifier for the particular given transaction, asopposed to any given transaction involving the user identifier. (Theverification process must take into account how selection of thecustomization parameter may affect what the verification agency willreceive for verification. Additional details regarding procedures thatcan be used to verify a one-time card number that can be customized areset forth in U.S. Pat. No. 6,609,654.) This difference is a reason whyuse of the one-time payment card number provides greater security andanonymity than can be obtained through use of a traditional paymentcard.

A card number generator generates a one-time payment card number. Asalready described, this could be hardware or software, but, in eithercase, it will preferably include a customer random number generator anda customer sequence number. It is especially preferred that the cardnumber generator be part of an electronic card, and that the electroniccard be of the type described in U.S. application Ser. No. 09/571,707filed May 15, 2000 for Anonymous Electronic Card for Generating PersonalCoupons Useful in Commercial and Security Transactions, or in U.S.application Ser. No. 09/667,835.

Several different methods can be used to generate a one-time paymentcard. No matter what method is used to generate a one-time payment cardnumber, two successive one-time payment card numbers should bedifferent. This can be accomplished by using a sequence number that ischanged after each one-time payment card number is generated. (Thepresent invention does not require that all theoretical possibilitieswill result in different one-time payment card numbers. Instead, it ispreferred that there be a low probability of occurrence of identicalone-time payment card numbers attributable to convergence of twodifferent inputs leading to the same result due to operations performedon the inputs by the algorithm.)

The preferred embodiments allow a user to customize use of an electroniccard having a card number that varies with each use by selecting atleast one customization parameter to customize a given use of theelectronic card. There are three general customization parameters thatcan be used to customize a given use.

First, the user can customize generation of the one-time card number.This can be done many different ways. An example of one way in which itcan be done is to customize selection of a selected user key that isused to generate the one-time card number as is explained in U.S. Pat.No. 6,609,654. Another way in which it can be done is to include acustomization variable in the one-time card number, or as an input intothe algorithm used to generate the one-time card number.

Second, the user can customize the user identifier that is used tovalidate the one-time card number. This can be done many different ways.One way is to choose one of two or more preselected identifiers as aselected user identifier. Another way is to modify the user identifier.Still another way is to add a customization variable, such as a numericcharacter, to the user identifier at a preselected location.

Third, the user can include a customization variable with informationtransmitted to a verification agency for validation of the given use.Unlike the first two customization parameters, this parameter reliesupon use of an additional field of data collected as part of thevalidation process for a given transaction, and this may require achange in established validation protocols. It is especially preferredthat any such change be technically feasible within the confines ofhardware that is being used to process traditional payment cardtransactions. In the context of an electronic card with a magneticstripe, this means that it is preferred that the additionalcustomization variable be stored in the magnetic stripe, and it isespecially preferred that it be stored in the second track of themagnetic stripe. Additional details regarding inclusion of acustomization variable in a magnetic stripe are set forth in U.S. Ser.No. 09/667,089.

Once it is recognized that using one or more of the foregoingcustomization parameters will customize a given transaction involvinguse of a one-time payment card number, and that such customization willseamlessly allow a user to transmit additional information to the moneysource processing such transaction, without loss of desired security oranonymity, the options for using such customization are virtuallylimitless.

After a one-time payment card number is validated for a giventransaction, the money source can determine what customizationparameter(s) was selected by the user for the given transaction, whichallows the money source to determine what handling option should be usedfor the transaction involving the one-time payment card number. (It alsoallows the money source to determine what sequence number is associatedwith the one-time payment card number, so that its records can besynchronized as part of the validation process.)

One use of multiple handling options is to allow the money source toaccess multiple accounts. For example, a user might use one account as acredit card, and another account as a debit or checking card. Bychoosing which account should be used for a given transaction, the usercould determine, at the point of use, whether to charge the transaction,or have it deducted from an existing account balance. The same ideacould be used for multiple credit cards, whether they are from the sameissuer or different issuers, or even different cards, such as Visa®,MasterCard®, Diner's Card®, Discover® or American Express®. In addition,the user might elect to have separate billing statements for separateaccounts, or have all billing consolidated in a single statement.

Another use of multiple handling options is to allow identification ofthe person completing a transaction, or to allow multiple persons accessto a single account, or place different restrictions on multiple personson a single account. For example, a single account might be opened withan issuing bank, but an entire family might be authorized to use theaccount. Thus, a father and a mother might have their own customizationparameter, a teenage child might have another customization parameterand a lower authorized spending limit, and a preteen child might have afourth customization parameter, but only be authorized to engage in acertain limited number of transactions per time period with a maximumspending limit for each transaction. All the members of this familycould use the same card number generator embedded within a PDA or mobilephone, or on a computer or in an electronic card. At the end of aspecified billing cycle, all transactions completed by any member ofthis family could be consolidated in a single bill, and that bill couldindicate who spent what when during the billing cycle, and what it wasspent on.

Still another use of multiple handling options is to allow a user toclassify the nature of a particular transaction at the time it iscompleted. For example, suppose an individual uses a single credit cardfor personal expenditures and business expenditures. By assigning onecustomization parameter to personal transactions, and a secondcustomization parameter to business transactions, the user can simplifyaccounting for such transactions without the necessity of having andcarrying two separate cards. If desired, the user could even receive twoseparate statements for such expenditures so that the personalexpenditures would not be discernable from the documentation associatedwith the business expenditures. Individual transactions could also beclassified according to a preselected set of criteria, and such criteriacould be used in various financial programs. For example, a user mightinclude a code classification system used in a money management systemto create various reports that itemize categories of spending or assistin budgeting of finances.

Yet another use of multiple handling options is to allow a user topreselect how a particular transaction is treated in a subsequent bill.For example, an individual user might not want a billing statement toinclude information about the identity of second entities who providecertain goods or services, or when transactions with such entities takeplace, but still want to have the billing statement include suchinformation for other transactions. By selecting two differentcustomization parameters with these two different handling options, theuser has the option of controlling what information it receives inbilling statements about individual transactions.

Multiple handling options can also be used to guard privacy, or forcommercial purposes that do not presently exist. For example, the userand the money source might enter into an agreement about how, and underwhat circumstances, the money source can distribute information abouttransactions of the user, depending upon which customization parameteris used in a given transaction. The agreement might provide differentlevels of confidentiality, and set up different levels or types ofcompensation tied to transactions falling within the different levelsfor a given time period.

One level of confidentiality might restrict distribution of anyinformation concerning a transaction by the money source to any thirdparty. For example, a user might want strict confidentiality of anytransaction involving medical services, and would not want the moneysource to divulge that information to any party unless legally requiredto do so. Or, maybe the user does not want any third party to learn ofany transaction that exceeds a certain dollar amount, for fear of apotential deluge of unsolicited advertising. A user might pay a monthlyfee for use of this option, a transaction based fee, or no fee at all.

A second level of confidentiality might permit distribution of anyinformation concerning a transaction by the money source to any thirdparty. Such information is potentially valuable for purposes ofadvertising, and creating profiles for targeted marketing, and the moneysource might even pay the user for the right to sell such information.

Other levels of confidentiality might fall between those already noted.For example, a third level might permit distribution of certaininformation concerning a transaction (such as the payee, the amount ofpurchase, the date of purchase, and a profile of the user), but restrictdistribution of other information concerning a transaction (such as theidentity of the user). Another level of confidentiality might restrictdistribution of information concerning a transaction to any third party,but allow the money source to use such information for its own marketingefforts directed to the user.

The teachings of U.S. Ser. No. 09/960,714, which has issued as U.S. Pat.No. 6,805,288, will now be discussed. This disclosure seeks to providenew methods for generating and processing Secure Card Numbers (SCN) thatcan be used in all types of transactions in which a conventional creditcard account number is accepted. In addition, this disclosure conformsto the existing standards for PIN encryption as promulgated by theAmerican Bankers Association (ABA), the American National StandardsInstitute (ANSI), the International Standards Organization (ISO), andthe Federal Information Processing Standards (FIPS) Publications of theNational Institute of Standards and Technology (NIST). Because themethodology is well suited for use in hardware and softwareapplications, it has widespread applicability to many different types oftransactions.

The present disclosure is related to the concept of customer one-timeunique purchase order numbers (“Coupons”) as described in U.S. Ser. No.09/640,044. An algorithm is executed that uses a user account number, acustomer sequence number, a customer permutated user key, and aTransaction Information Block (TIB) as input variables to form an SCNthat is correlated with a sequence number. Combining a user key with auser account number, a user insertion key correlated with the customersequence number, and then encrypting the result using the Triple DataEncryption Standards (TDES), forms the customer permutated user key. Arandom number generator generates the user insertion key that iscorrelated with the sequence number. The TIB may provide several piecesof information, including the conditions under which the SCN will bevalid (i.e., the SCN type), additional account identificationinformation, and the status of the device used for SCN generation. Thesequence number can be changed after each SCN is generated and a new SCNcan then be generated using a new user insertion variable correlated tothe changed sequence number.

After an SCN is generated, it is transferred with a first entityidentifier to a second entity (which can actually be several entities),which then transfers the information to a money source. An individualSCN is verified as being valid by the money source by duplicating thegeneration of the customer permutated user key for the specified firstentity and the specified sequence number, and then comparing it to thecustomer permutated user key which is embedded in the provided SCN.Additionally, the money source verifies that the specified SCN type isvalid given the specific conditions of the transaction. Once verified asvalid, each SCN passes through a life cycle in accordance withconventional credit card processing practices and with its SCN type, inwhich it may be used for various types of transactions before beingretired. If a preselected number of SCNs are received by the moneysource and determined to be invalid (either consecutively or within apredetermined timeframe), then an invalid user account number conditionis set to prevent further attempts to verify SCNs for that first entity.

A user key can be entered into an input device which validates the userkey by comparing it to a stored user key. If the entered user key isvalid, the user can generate an SCN. The sequence number changes eachtime a user key is entered into the input device.

A preferred embodiment of this disclosure is adapted for use in creditcard transactions, and as such can be used in connection with a widevariety of instruments that can be used in connection with suchfinancial transactions: electronic cards, software programs used innetwork applications, telephones (especially telephones used in what isnow being referred to as m-commerce, or mobile commerce), or evenphysical imprint transactions. Moreover, it can be used whether suchtransactions are conducted in person, face-to-face, or whether suchtransactions are conducted by an indirect medium, such as a mail ordertransaction, a transaction conducted over a computer network (forexample, the Internet), or a telephone transaction.

As is the case in most financial transactions, three parties aretypically involved in completed credit card transactions according tothe present invention. A party presents a credit card account numberwith the intent to initiate a monetary payment (or credit/return). Inthe context of the following description, this is the first entity orcustomer. Another party receives the credit card account number with theintent to receive a monetary payment (or credit/return), and this partycan be a single party or two or more parties. In the context of thefollowing description, the party or parties that are receiving thecredit card account number are referred to as the second entity ormerchant. Finally, there is at least one party, and usually multipleparties, that serve as intermediaries to the monetary payment (orcredit/return). The second entity provides the credit card accountnumber to this party over several transactions to effect the monetarypayment (or credit/return): authorization, incremental authorization,authorization reversal, settlement, and credit/return. The intermediarygroup of one or more parties will be referred to in the context of thefollowing description as a money source. Thus, the money source may beone or more banks, a credit card company or any other institutioninvolved with issuance of credit cards or bank debit cards, such as acredit union or other institution, or a money source as described inU.S. Pat. No. 5,913,203.

In connection with this embodiment, it is not necessary that the firstentity use a real identity, although such an option is also acceptable.Instead, a pseudonym, such as a screen name or an alias, could be usedto protect the first entity's privacy and provide additional security.

Although the first entity need not use a real identity, the first entitymust establish an account with a money source. When the account isestablished, the first entity and the money source must agree upon apayment mechanism or protocol. In the case of a credit card or a bankcard, this could be done in the same fashion as exists today, and thefirst entity could select a fictitious account name as is explained ingreater detail in co-pending U.S. patent application Ser. No.09/619,859. It is especially preferred that two different users not beallowed to select the same fictitious account name so that a fictitiousaccount name also represents a unique identifier. However, the preferredembodiment could also be used in connection with a prepaid account. Insuch a scenario, the first entity could simply purchase a prepaid cardand no real identity would ever be required.

When the first entity establishes an account with the money source, auser key must be selected. The user key can be a PIN, similar to thatwhich is currently in widespread use in the United States in connectionwith automated teller machines. Both the first entity and the moneysource must have access to the user key, which can be selected by eitherentity. In order to be able to retrieve this user key, the money sourcemust create a record associated with the first entity that includes theuser key and a first entity identifier (whether this be the real name ofthe first entity or a fictitious account name).

Once the first entity has established an account with the money sourceand a user key has been selected, the first entity must be supplied withthe means to generate a customer SCN. As already described, this couldbe hardware or software, but in either case it will include a useraccount number, a customer random number generator that will be used togenerate user insertion keys that are correlated with a customersequence number, and TDES encryption keys.

The TDES encryption standard is the accepted standard for protecting aPIN during data transmission of financial transactions, as described byISO 9564-1-1991 (Banking—Personal Identification Number Management andSecurity—PIN Protection Principles and Techniques, Section 6.2), ISO9564-2-1991 (Banking—Personal Identification Number Management andSecurity—Approved Algorithms for PIN Encipherment), ANSI X9.52-1998(Triple Data Encryption Algorithm—Modes of Operation), and FIPS PUB 46-3(Data Encryption Standard (DES), dated 1999), the disclosures of whichare specifically incorporated herein by reference.

In order to effectively use TDES for PIN encryption, the PIN must becombined with a new set of randomly generated data for each transaction.Otherwise, the encrypted PIN would always be the same value. A customerrandom number generator, such as the one that is described in U.S.patent application Ser. No. 09/640,044, filed Aug. 15, 2000 and which isgenerally known as a Linear Congruential Generator (LCG), is used forthis purpose. This random number generator is algorithmic (i.e.,pseudo-random)—when starting with the same set of seeds, it alwaysproduces the same sequence of numbers. It can therefore be reproduced bythe money source in order to validate a given SCN. Furthermore, sincethis pseudo random number generator generates its values in areproducible sequence, each of the values in the sequence can beidentified by a Counter value that indicates that numbers location inthe sequence. The set of random numbers generated and combined with thePIN are collectively referred to as the Sequence Insertion Number (SIN).

In the real world of credit card transactions, it is not possible toassume that transactions conducted by the first entity in a given orderwill always be received by the money source in that same order.Therefore, the money source method of SCN validation must be based on anembedded sequence value. The Counter value is used for this purpose inthe preferred embodiment.

In general, this method can be used to generate SCNs of many differentlengths. In the conventional credit card processing infrastructure, acredit card number is typically 16 digits in length. Such a numbercomprises three sub-numbers: a 6 digit Bank Identification Number (BIN),a 9-digit account number, and a 1-digit checksum number. For the purposeof being compatible with the existing credit card processinginfrastructure, the SCN could be 9 digits in length, and could take theplace of the account number in the conventional 16-digit credit cardnumber.

In a preferred embodiment, the 9-digit SCN itself comprises threesub-numbers: a 1 digit TIB, a 4 digit Counter Block (which identifiesthe random number being used for encryption), and a 4 digit encryptedPIN Block.

The 1 digit TIB may take on up to 10 different values, each of which mayindicate multiple pieces of information. The TIB can be used todetermine which of a plurality of account numbers associated with thefirst entity should be used for the first transaction. The accountnumbers can represent, for example, different credit card accounts ordifferent payment or credit cards. A first account number might beassociated with the TIB value of 0, a second account number might beassociated with the values of 1 and 2, a third account number might beassociated with values of 3 and 4, and so forth, wherein any odd valuemay be restricted to a one transaction limitation while any even valuemay be used to invoke permission for multiple transactions at a singlemerchant. In the preferred embodiment, a TIB value of 0 indicates thatthe SCN may only be used for one transaction; any attempts to use it forsubsequent transactions will result in a transaction denial from themoney source. A value of 1 indicates the same transaction restrictionsas 0, but also indicates that the device generating the SCN has a lowbattery power condition. A low battery power condition can be detectedby a diagnostic program or it can be extrapolated from an empiricalrecord (or counter) of the number of transactions presented forauthorization. The transaction counter used to extrapolate a low batterpower condition can be collected from the firmware used to generate SCNsor from software behind the money source firewall. A value of 2indicates that the SCN may be used for multiple transactions, but onlyat a single merchant; any attempts to use it for subsequent transactionsat a different merchant will result in a transaction denial from themoney source. A value of 3 indicates the same transaction restrictionsas 1, but also indicates that the device generating the SCN has a lowbattery power condition. Furthermore, a set of TIB values (4, 5, 6, 7)might represent the same restriction and status information as (0, 1, 2,3), respectively, but further indicate that the transaction isassociated with a different subentity (e.g., the first entity identifieridentifies a married couple, and the TIB identifies each individualspouse.) Other values might also be used to enforce additionaltransaction restrictions in ways readily apparent to those skilled inthe art.

The TIB can also be used by the money source to uniquely identify aphysical device (such as an electronic card) used to generate the SCN.This aspect of the TIB is especially useful when the money source issuesmore than one card to a first entity. Multiple cards might be issued tothe same person (i.e., the first entity) for different uses, or multiplecards might be issued to the same person for use by differentindividuals (such as family members). In such instances, the TIB canidentify which physical card, issued to the first entity, is used for agiven transaction. When the TIB is used in this way, the TIB can be usedas a customization variable to recognize multiple cards otherwise issuedto a single first entity (which might also be a legal entity, such as acorporation).

The 4-digit Counter Block is unencrypted information provided so thatthe money source may decrypt and validate the SCN. It may be simply theactual Counter value (incremented after each use), but in the preferredembodiment, it is created by adding the Counter value to a startingvalue known to both the first entity and to the money source.

The 4-digit PIN Block is the encrypted information that is used tovalidate the fact that the SCN originated from the first entity. The PINBlock is formed using the PIN, the SIN, and a starting value known toboth the first entity and to the money source. It is encrypted usingTDES, which requires use of three 64-bit keys known to both the firstentity and to the money source. In order to encrypt such a small number(16 bits) with such a high level of encryption (158 bits), the PIN mustfirst be expanded to a 64 bit number, then encrypted, and finallyreduced back to a 16 bit number—and in such a way that it is guaranteedto be different for each transaction.

The SIN is the product of an LCG random number generator that isinitialized with three 2-byte integer seeds—the result of operating theLCG on these seeds is a 2-byte random value. The 8-byte SIN consists ofthe three seeds plus the random value. As a by-product of its operation,the LCG also produces three new seeds, which will be used for the nextiteration of the LCG algorithm. The SIN may therefore be associated witha Counter value that indicates a unique location in the sequence ofseeds and value generated by the LCG. This SIN is used as the randombasis for each successively TDES-encrypted PIN Block, and guarantees aproperly encrypted PIN Block for each transaction. To allow propervalidation of the SCN, the Counter value stored in the Counter block isthe one associated with the SIN used as the random basis for the PINBlock.

The creation of the PIN Block starts by dividing the 8-byte SIN intofour 2-byte integers. The PIN and a predefined constant value are bothadded to each individual 2-byte integer. The results are thenconcatenated back again to form an 8-byte input block to the TDESalgorithm, which encrypts them into an 8-byte output block. The outputblock is then divided back into four 2-byte integers (x1, x2, x3, x4).These four values are then used in the following formula to produce the4-digit PIN Block value P:

Formula 1: PRNG Value Calculation

In this formula, the four values (A, B, C, D) are each odd integers. The“mod” calculation is a standard modulo arithmetic operation, and worksas follows: if the resulting number is greater than 10,000 (or 20,000 or30,000, etc.), then the value of 10,000 (or 20,000 or 30,000, etc.) issubtracted from it, leaving a positive four digit value.

Once created, the SCN is transmitted along with the first entityidentifier from the first entity to the second entity and, subsequently,to the money source.

In one embodiment, the SCN is used in an account number that replacesthe conventional credit card number, and the first entity identifier isa static 9 digit number pre-assigned to the first entity that istransferred to the money source in a non-account data field. In the caseof an electronic swipe credit card transaction, the first entityidentifier is dynamically encoded onto Track 1 and/or Track 2 of themagnetic stripe in the area known as the Discretionary Data Field, whichcomprises up to 13 digits of information. In the case of a transactionwhere the first entity is not present, such as a mail order, telephoneorder, or Internet order, the first entity identifier is transmitted aspart of the Billing Address field in one of many possible forms. Forexample, it may be entered as “P.O. Box <first-entity-identifier”.

In an especially preferred embodiment, the SCN is not used in an accountnumber to replace the conventional credit card number, but is insteadused in conjunction with it—the conventional credit card number itselffunctions as the first entity identifier, and the SCN is used as adynamic digital signature to positively identify the first entity and istransferred to the money source in a non-account field of data. In thiscase, the SCN is transmitted either in the Discretionary Data Field ofTrack 1 and/or Track 2 or via the Billing Address in a card-not-presenttransaction.

The Money Source validates the SCN by using the first entity identifierto lookup the information necessary to reproduce the PIN Blockencryption for the first entity: the TDES keys, the LCG Seeds, and thePIN. The Money source determines the Counter value by examining theCounter Block, reproduces the calculation of the PIN Block, and thencompares the results to the received PIN Block to perform the actualvalidation.

The Money Source also validates the usage of the SCN based on theembedded TIB. It therefore enforces the various policies based on thefirst entity's previous transaction history: single-use, multiple-usefor single merchant, card-present only.

In the embodiment when the SCN is used in an account number in place ofthe conventional credit card number, it passes through the standardcredit card transaction life-cycle: initial authorization, potentialincremental authorization, potential authorization reversal, settlement,and potential credit/return. However, in an especially preferredembodiment, the SCN is only used for initial authorization—beyond that,the Money Source performs its standard transaction processing.

The Money Source may detect fraudulent transaction attempts in variousways. In both the embodiment where the SCN replaces the conventionalcredit card number, the Money Source may check for re-use of single-useSCNs, use of SCNs without first entity identifiers when the card is notpresent, re-use of multiple-use/single-merchant SCNs at a differentmerchant, or SCNs with invalid PIN Blocks. Each of these casesrepresents a different type of fraud. The Money Source may take variousactions in response to each of these types of attacks, such as disablingthe account after an excessive number of fraudulent transactionattempts, or returning the code indicating that the merchant shouldretain the credit card being used for the transaction.

In the preferred embodiment, the Money Source detects fraudulentauthorization attempts such as re-use of single-use SCNs, re-use ofmultiple-use/single-merchant SCNs at a different merchant, SCNs withinvalid PIN Blocks, or use of the conventional credit card number on anSCN-enabled account without inclusion of an SCN when the card isnot-present. This last case covers simple Internet fraud attempts, butallows, for example, a manual-entry transaction at a POS machine or animprint transaction. After detecting fraud attempts, the Money Sourcemay take the same types of actions as described above.

It should be noted that the preferred embodiment allows the SCN, whenpaired with a conventional credit card number, to be validated byback-end software that is integrated with the issuing money source'sauthorization and settlement processing. An issuing money source canidentify an SCN-enabled credit card account in an issuer-determinedfashion (e.g., a unique Bank Identification Number). It then forwardsselect transaction information to the SCN-enabling software, which isinstalled behind the issuing money source's firewall, which validatesthe SCN. This means that software generating the SCN can be allowedoperate in isolation—it does not have to be in communication with theback-end software—and thus it can be embedded in a credit card or otherstandalone device.

The inventions described above can be implemented by a money source foruse with an electronic card. It is preferable that every user accountutilizes the same Pseudo Random Number Generator (PRNG), such as thePRNG described in P. L'Ecuyer, “Efficient and Portable Combined RandomNumber Generators”, Communications of the ACM, 31(6):742-749,774, 1988,the disclosure of which is specifically incorporated herein byreference. However, each cardholder account has a different initialseed, and thus uses a different part of the PRNG sequence. Since thePRNG has an overall period of 10.sup.12, there is ample room for eachaccount to have its own non-repeating subsequence of 10,000 values.

The PRNG is divided into two parts: seed generation (Formula 2) andvalue calculation (Formula 3). In these formulas (expressed using C codefragments), the set (S.sub.x.sup.0, S.sub.x.sup.1, S.sub.x.sup.2) is atriplet of five-digit values in the range ([1,32362], [1,31726],[1,31656])), and represents the seed in the x.sup.th location in thesequence. Z is interim storage for the pseudo random number, and PRNG[x]indicates the pseudo random number in the x.sup.th location in thesequence. Note that for the practical usage of this algorithm, “x”corresponds to the current Counter value. For each transaction, Formula2 generates the seed (based on the previous seed) and Formula 3generates the PRNG value.

Formula 2: PRNG Seed Generation Formula 3: PRNG Value Calculation

In all cases, the initial PRNG seed (which generates value 0 in the PRNGsequence) is pre-assigned to the card. Additionally, the most recentlyused seed is stored in Random Access Memory (RAM). Thus, when an SCNmust be generated, the card runs through both Formulas 2 and 3 exactlyonce, and then updates the seed storage in RAM. The Counter value isalso stored in RAM, and is initialized to the value of 1 at the time thecard is manufactured. Multiple values of the Counter are stored todetect accidental corruption. Each time an SCN is generated, the currentvalue of the Counter is used. The Counter is then incremented by 1, andstored again for the next use.

Since the SCN is calculated in an algorithmic fashion, it is possible topre-calculate the values for a given first entity, and store them on anelectronic card. This embodiment is most useful where it is moreadvantageous to store a large amount of data on the electronic card thanit is to perform the algorithms discussed above.

Use of the SCN technology described herein is secure when it requiresthe cardholder to enter a PIN in order to generate a unique SCN that isvalid for only one transaction, and for only the specified cardholder.At no time during the transaction is the PIN at risk. By utilizing bothencryption and random number generation technologies described herein,it is possible to achieve at least a 99.9% level of protection againstfraud.

Thus, this disclosure teaches a method for providing one or more securetransactions between a first entity and at least one additional entity,comprising the steps of: (1) using an electronic card to generate aSecure Card Number (“SON”) for the first entity, wherein the SCN iscomprised of: (a) a Transaction Information Block (“TIB”); (b) a CounterBlock; and (c) an encrypted Personal Identification Number (“PIN”)Block; (2) transferring the SCN and a first entity identifier to asecond entity in a first transaction; (3) transferring the SCN and thefirst entity identifier from the second entity to a money source; and(4) verifying that the first transaction is valid with the money sourceby use of the first entity identifier and the SCN; wherein the TIB canbe used for invoking one or more restrictions on use of the SCN; andwherein the TIB is used by the money source to determine whether thedevice which generated the SCN has changed status condition. The changedstatus condition can be a low battery condition detected by a diagnosticprogram or by using an empirical record of the number of transactionspresented for authorization and determination of the low batterycondition can be made by the electronic card which also keeps theempirical record. Alternatively, determination of the low batterycondition is made by the money source which the empirical record. Thechanged status condition can also be an invalid user input status.

Although the foregoing detailed description is illustrative of preferredembodiments of the present invention, it is to be understood thatadditional embodiments thereof will be obvious to those skilled in theart. Further modifications are also possible in alternative embodimentswithout departing from the inventive concept.

Accordingly, it will be readily apparent to those skilled in the artthat still further changes and modifications in the actual conceptsdescribed herein can readily be made without departing from the spiritand scope of the disclosed inventions as defined by the followingclaims.

What is claimed is:
 1. An electronic device powered by a power sourcewhich is capable of communicating with a read head of a magnetic stripreader, comprising: a user selection mechanism operable to allow a userto select a customization variable for a single transaction of theelectronic device; a processor for generating a transaction specificdata packet that includes an account number and a customized number; andan electronic communication device operable to cause the data packet tobe read by the read head when the electronic device is positioned withina preselected distance of the read head; wherein the electroniccommunication device is operable to dynamically convey the transactionspecific data packet to the read head so that the transaction specificdata packet is read by the read head when the electronic device ispositioned within a preselected distance of the read head; wherein thetransaction specific data packet is dynamically generated for use by theelectronic device for the single transaction of the electronic deviceand the customized number is determined based upon the customizationvariable selected by the user selection mechanism; and wherein theaccount number is a fixed number that can be used by the electronicdevice for a plurality of consecutive transactions of the electronicdevice without changing and the customization variable may or may notchange for any given transaction of said plurality of consecutivetransactions depending upon a user selection for said any giventransaction.
 2. The electronic device of claim 1 wherein the transactionspecific data packet includes a piece of data that is generated by acryptographic algorithm in response to an input from the user selectionmechanism.
 3. The electronic device of claim 1 wherein the device numberand a cryptographic key are stored in the device and accessible by theprocessor.
 4. The electronic device of claim 1 wherein the userselection mechanism is a plurality of buttons that allow the user toselect between a plurality of transaction device functions.
 5. Theelectronic device of claim 4 further comprising a visual display forindicating a selection of a particular transaction device function. 6.The electronic device of claim 1 further comprising a display fordisplaying at least a portion of the transaction specific data packet tothe user.
 7. The electronic device of claim 1 further comprising adisplay for visually displaying the device number.
 8. The electronicdevice of claim 7 wherein the device number is visually displayed in thedisplay in response to an input from the user selection mechanism. 9.The electronic device of claim 1 wherein the electronic communicationdevice is comprised of an electronic encoder.
 10. The electronic deviceof claim 1 wherein the device does not contain a magnetic stripe. 11.The electronic device of claim 1 wherein the user selection mechanism isoperable to allow the user to specify whether the single transaction ofthe device is for business or non-business use.
 12. The electronicdevice of claim 1 wherein the user selection mechanism is operable toallow the user to select one of at least two different handling optionsby which the user is billed for the single transaction of the device.13. The electronic device of claim 1 further comprising a diagnosticfunction accessible by the processor which generates information that isstored the transaction specific data packet.
 14. The electronic deviceof claim 13 wherein the diagnostic function measures at least oneparameter and generates a warning signal that is stored in thetransaction specific data packet when a preselected threshold isexceeded.
 15. The electronic device of claim 1 wherein the transactionspecific data packet includes a block of data formed by using a TripleData Encryption Standard algorithm to encrypt a personal identificationnumber.
 16. The electronic device of claim 1 wherein the electronicdevice is comprised of a telephone.